Communication technology has made considerable progress in recent years. Concerning especially packet-switched communication networks, an ever rising demand for fulfilling differentiated QoS requirements, e.g. sophisticated PHB (per hop behavior), has emerged. Such differentiated QoS requirements are necessary to accommodate e.g. a data packet stream belonging to a VoIP (Voice over Internet Protocol) end-to-end connection between e.g. mobile stations of one or more end users, which VoIP data packet stream requires a higher priority for its data packets to hop from one network node to another than e.g. a data packet stream associated with a data download between two data terminals. Both of the above data packet streams may be relayed over one or more common routers, resulting in a need to prioritize the VoIP data packet stream, which is more sensitive to e.g. data packet loss, data packet travel delay, data packet travel delay variation (“jitter”) and data packet arrival misalignment, over the data download data packet stream being less sensitive to such effects.
The terminal(s) of the one or more end user(s) of the end-to-end connection may access the packet-switched network via an access technology, e.g. the WiMAX (Worldwide Interoperability for Microwave Access) technology. Other access technologies may be deployed, like e.g. WLAN (Wireless Local Access Network), xDSL (Digital Subscriber Line), xPON (Passive Optical Network) or a cable modem. The end-to-end connection may be terminated by a gateway entity (connected e.g. to a base station) of a network element.
For the purpose of the present invention to be described herein below, it should be noted that                an access technology may be any of the above-described technologies by means of which a terminal can access a communication network. Although in the following only WiMAX is used as an exemplary access technology for descriptive purposes, other present or future technologies, such as the technologies described above or BlueTooth©, Infrared, and the like may be used; although the above technologies are mostly wireless access technologies, e.g. in different radio spectra, access technology in the sense of the present invention may also imply wirebound technologies;        a terminal in turn may for example be any device, unit or means by means of which a user accesses a communication network, i.e. at least one network element thereof; this implies that a terminal as referred to in the present specification may correspond to a mobile as well as a non-mobile device, independent of the technology platform on which the terminal is based;        generally, the present invention is advantageously applicable in those network/terminal environments relying on a data packet based transmission scheme according to which data are transmitted in data packets and which are for example based on the Internet Protocol IP. In particular examples of the present invention, IPv4 (IP version 4) and IPv6 (IP version 6) are applied. The present invention is, however, not limited thereto, and any other present or future IP or MIP (mobile IP) version, or, more generally, a protocol following similar principles as IPv4 and/or IPv6, is also applicable;        a data packet may for example be any data structure for network traffic, comprising a header section and a data payload section, and consisting of information elements (e.g. bits) in a consecutive (e.g. in signal bursts) or distributed (e.g. spreading codes) fashion;        a data packet header is for example any data structure comprising at least one information element required for network traffic routing, and may be, despite of its name, a heading, a trailing or an intermediate data structure for its associated data packet;        a network element may for example be any device, unit or means by means of which a terminal may have access to a communication network and that provides gateway functionality for enabling a terminal to experience services provided by the communication network;        an access entity as a network element or at least as a part of a network element may for example be any device, unit or means by which a user can access to a communication network based on an access technology;        a gateway entity as a network element or at least as a part of a network element may be any device, unit or means by which the access termination for the terminals of an end-to-end connection can be performed;        an anchor may for example be any functionality which in case of a mobile terminal provides, in the connection path from the communication network to the mobile terminal, the last location at which the connection is relayed over a fixed entity. In case of e.g. the gateway entity providing anchor functionality, the access entities following in the communication path may be selected according to the requirements of e.g. a handover between access entities;        a U-plane (user plane) may for example refer to a hierarchic layer in a communication network dedicated to user data;        a C-plane (control plane) may for example refer to a hierarchic layer in a communication network dedicated to signalling;        a routing entity may for example be any device, unit or means, which is situated between the network elements or is formed integrally in at least one network element, for routing data packets from one end-to-end termination to another;        method steps likely to be implemented as software code portions and being run using a processor at the network element, are software code independent and can be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved;        generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention in terms of the functionality implemented;        method steps and/or devices, units or means likely to be implemented as hardware components at a terminal or network element or module thereof are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components;        devices, units or means (e.g. network elements or modules thereof) can be implemented as individual devices, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, unit or means is preserved.        
Various approaches have been conducted in order to provide and to manage differentiated QoS requirements.
One such approach suggests a so-called drop eligibility marking for the data packets of BE (Best Effort, per default lowest PHB priority) network traffic as drop eligible. In case the data packets of BE traffic interfere with data packets of a Critical Application, the BE traffic data packets may be dropped.
Another approach defines a so-called DSCP (Differentiated Services Codepoint) to be bit #0 to bit #5 of the data packet header's IPv4 ToS (Type of Service) field or IPv6 Traffic Class field, respectively, and introduces three pools of codepoints, namely Pool 1:xxxxx0, Pool 2: xxxx11, Pool 3: xxxx01, wherein x can adopt the bit values 0 and 1.
FIG. 1 shows an example architecture (as e.g. applied in the WiMAX Forum QoS architecture) of a communication network 100 comprising an ASN (Access Service Network) 101, a mobile station MS 102 and a NSP (network service provider) network 103.
The network element 101 comprises a base station BS 1011 for SFM (Service Flow Management), which may constitute an access entity 1011, a Serving ASN-GW (ASN-Gateway) 1012 for SFA (Service Flow Authorization), which may, together with a U-Anchor (User plane anchor) ASN-GW 1014 e.g. for MS 102, constitute a gateway entity 1012, 1014, and a C-Anchor (Control plane anchor) ASN-GW 1013 e.g. for MS 102.
The NSP network 103 comprises a Home NSP 1031 and a Visited NSP 1032, through which ASN 101 is arranged to acquire e.g. the subscriber QoS profile of the MS 102 from an AAA (Authentication, Authorization and Accounting) entity via, if necessary, a PAAA (Proxy AAA) entity of the Visited NSP 1032.
For further details concerning e.g. definitions of the reference points R1 to R6, see WiMAX Stage 2 and 3 specifications, which provide extensive capabilities for QoS handling in both Control and User Planes. As shown in FIG. 1, the QoS functionality is very sophisticated, enabling checking against local policies in several domains by means of e.g. PFs (Policy Functions) performed on the basis of the Home and Visited NSP policy data bases, and by means of the Local Policy Database in or accessible to the gateway entity 1012, 1014 and the Local Resource Information in or accessible to the access entity 1011.
The resulting complexity is very high at the Control Plane and may potentially be too strict at the User plane.
Concerning handling of QoS enforcement in the existing WiMAX architecture according to FIG. 1, this QoS enforcement is performed either in the U-anchor ASN-GW 1014 according to FIG. 2 or the Serving ASN-GW according to FIG. 3.
Both schemes for QoS enforcement shown in FIGS. 2 and 3 are either too strict or suboptimal in their location. In the case of U-anchor QoS enforcement (see FIG. 2), there is a significant potential of dropping data packets unnecessarily. In this context, unnecessarily can be considered from two different points of view, being the one of the terminal's end user and the one of the (communication) network operator.
In some cases, network operators may desire to enforce a certain level of QoS if network resources are limited e.g. due to limited UL/DL (Uplink/Downlink) capacity of e.g. a mobile station and/or network congestion occurrence, while providing a better level of service is of less significance as long as the above problems do not impose a limiting factor. One of example therefore resides e.g. in traffic during off-peak hours, especially at night when the traffic load on the network is relatively low. In many cases, time-dependent policies (depending e.g. on times of traffic peak, off-peak, night, etc.) tend to become too complex to manage and to provide, and might be too restrictive without taking into account current traffic conditions (for example, some end users deciding to perform resource-consuming corporate backup services at night).
End users might also experience service degradation even below their signed QoS level e.g. because of network data packet bursts. In general, connection between a CSN (Connectivity Service Network), like e.g. a HA (Home Agent) according to FIGS. 2 and 3 for seamless service continuity and the U-anchor ASN-GW 1014 may be performed at very high speeds (e.g. 1 Gbps to 10 Gbps). In most cases, the routing entities transmit, per default behaviour, data packets in data packet bursts, i.e. data packets are buffered for some amount of time and are transmitted substantially at the same time. Such data packet bursts can cause short-peak rates for a specific end user that might cause unnecessary data packet drop.
In the case of QoS enforcement in Serving ASN-GW 1012, as shown in FIG. 3, a potential intermediate network between the U-anchor ASN-GW 1014 and the Serving ASN-GW 1012 (in FIG. 3, only a single R4 connection is shown, but in general, multiple R4 connections are possible) might be imposed with a heavy traffic load.
In this context, still another approach suggests to utilize a so-called ECN (Explicit Congestion Notification) field consisting of bit #6 (ECT: ECN-capable transport) and bit #7 (CE: Congestion Experienced) of the data packet header's IPv4 ToS field or IPv6 Traffic Class field, respectively, for routing data packets. This is achieved by:                1. Communicating between the terminals so as to detect whether or not both terminals are mutually ECN-capable, i.e. whether or not the ECN field will be handled.        2. Marking each data packet based on the detected ECN-capability in the ECN field by the sending terminal.        3. Relaying data packets for the end-to-end connection via at least one ECN-capable routing entity depending on the ECN field and depending on whether the number of data packets in the queuing entity is between a minimum threshold and a maximum threshold. Therein, ECN field “00” indicates lack of ECN-capability, and the data packet may be dropped based on other QoS considerations. ECN fields “10” and “01” (referred to as ECT(0) and ECT(1)) are treated the same, namely the ECN field is changed to “11” if the data packet would have been dropped based on QoS considerations, and the data packet is relayed further.        4. Relaying further data packets, wherein data packets having an ECN field 11 are interpreted as network congestion, again depending on whether the number of packets in the queuing entity is between a minimum threshold and a maximum threshold, and are relayed even further.        
Therefore, the above approach has one or more of the following drawbacks:                It is slow and inflexible:                    Before starting the actual service, both terminals have to detect and confirm mutual ECN-capability.                        It is vulnerable to ECN-incapability:                    If there is only one ECN-incapable routing entity in the path of the end-to-end connection between the terminals, the ECN field will be ignored, and the corresponding data packet may be dropped depending on QoS considerations.                        It is difficult to be implemented in existing networks:                    Considering the fact the data packets in an end-to-end connection may be routed on substantially any arbitrary path from one routing entity to another, the entire network must be configured to ECN-capability to ensure full ECN-compliance.                        It does not provide Qos granularity and/or congestion Granularity:                    ECN-compliance only allows a basic determination between conforming/non-conforming with a QoS requirement and between congested/not congested of the at least one routing entity.                        